13.2 KB · ⇊ 5 parts · ⤓ Micron 13.2 KB · ⤓ HTML 26.0 KB

top

Il mwcgdebugging (o semplicemente mwcwdebug) o mwdadepurazione, in mwdqinformatica, nell'ambito dello mwdgsviluppo software, indica l'attività che consiste nell'individuazione e correzione da parte del mwdwprogrammatore di uno o più errori (mweabug) rilevati nel mweqsoftware, direttamente in fase di mwegprogrammazione oppure a seguito della fase di mwewmwfatesting o dell'utilizzo finale del mwfqprogramma stesso.

L'attività di debug è una delle operazioni più importanti e difficili per la messa a punto di un mwfwprogramma, spesso estremamente complicata per la complessità dei software in uso e delicata per il pericolo di introdurre nuovi errori o comportamenti difformi da quelli desiderati nel tentativo di correggere quelli per cui si è svolta l'attività di mwgadebug.

• Operazioni di base

• Rilevazione dell'errore

• Accorgimenti per accelerare il processo di debug

• Corretto atteggiamento mentale

• Usare file di log

• Fare attenzione all'input fornito al programma

• Memorizzare le tipologie di errori

• Accorgimenti per ridurre la necessità di debug

• Disegno del codice

• Leggibilità del codice

• Commenti

• Voci correlate

• Altri progetti

• Collegamenti esterni

Sebbene ogni sessione di debug sia unica e costituisca una storia a sé, alcuni principi generici sono applicabili a tutte le sessioni di debug. In particolare, per il debug di applicazioni software, in genere si possono riconoscere cinque fasi nel debug:

• identificazione del bug

• individuazione del componente in cui è presente il bug

• individuazione della causa del bug

• progettazione di una correzione per il bug

• implementazione e testing della suddetta correzione

Mentre gli mwjqerrori di sintassi sono tipicamente evidenziati dall'mwjgIDE, alla fine della stesura del codice il programmatore opera una seconda fase di test valutando se l'output del programma è quello atteso compilando/interpretando ed eseguendo il codice. All'eventuale rilevazione dellmwjw'mwkaerrore di semantica e di mwkqruntime segue la fase di mwkgdebugging, ossia di individuazione della parte di mwkwsoftware, a volte molto complesso, nella quale si annida l'errore. Spesso tale operazione viene svolta dal programmatore di pari passo con la stesura del codice stesso, testando continuamente il codice ed evitando così l'accumulo degli errori.

Questa attività è supportata da programmi specifici (mwlqdebugger) messi a disposizione dall'IDE grazie anche all'uso di mwlgbreakpoint su linee di codice e dai messaggi di mwlwstandard error emessi nei mwmafile di mwmqlog (es. rilevamento mwmgeccezioni nelle console dell'IDE), che indicano e mostrano allo mwmwsviluppatore l'esecuzione, mwnaistruzione per istruzione, del programma, permettendo nel contempo l'analisi dei dati trattati dal programma stesso. In assenza di tali strumenti per le attività di mwnqdebugging, si ricorre alla più semplice, ma anche meno efficace tecnica di stampare a mwngvideo o su mwnwfile le istruzioni che il programma sta eseguendo, inserendo a tal scopo nel codice delle istruzioni di mwoadebug che evidenzino il punto di arrivo dell'esecuzione del programma fino all'errore. Sempre a questo scopo, il programmatore può, con l'ausilio dei mwoqcommenti, far eseguire solo alcune parti del codice o al contrario non far eseguire particolari parti del codice, sospette di causare l'errore. Una volta individuato l'errore nel codice il programmatore corregge l'errore in maniera iterativa finché il programma non fa ciò che è desiderato.

Una terza fase di debug è quella che il programmatore deve risolvere quando il software prodotto è stato mandato in fase di mwowtesting o mwpacollaudo al rispettivo team ed è stato rimandato indietro con la lista dei difetti riscontrati; in genere in questi casi molto spesso sono presenti errori nella stesura o interpretazione delle specifiche rispetto a ciò che è realmente desiderato senza andare in errore.

Una quarta fase di debug può avvenire quando in fase di utilizzo del programma da parte dell'utente finale questi riscontra delle anomalie; in genere in questi casi si ingenera un errore con relativo messaggio che viene inviato tramite mwpgInternet alla casa produttrice del software che aggiornerà periodicamente con nuove mwpwrelease senza errori o mwqaaggiornamenti il prodotto (es. mwqqMicrosoft Windows).

È necessario fare autocritica, e accettare il fatto che il programma non si comporta come dovrebbe e che si è fatto un errore, cosa del tutto normale e frequente in fase di sviluppo; se tutto fosse stato previsto e non ci fossero errori, il programma funzionerebbe correttamente, ma spesso questo risultato non si ottiene quasi mai alla prima stesura del codice, ma solo per successive modifiche e correzioni. Tale atteggiamento mentale incrementa significativamente la possibilità di trovare e risolvere dei bug.

Oltre all'uso della console dell'IDE è opportuno creare uno o più mwrwfile di log che può risultare molto utile per verificare se il programma funziona come previsto, e cosa succede prima, dopo e durante il verificarsi del malfunzionamento.

Tutti gli mwsginput forniti dall'utente devono essere validati prima mwswsintatticamente e successivamente anche mwtasemanticamente dal programma prima di essere elaborati. Ciò migliora anche la sicurezza del programma.

Nel caso si siano già scritti dei programmi simili e ci si sia trovati a bug simili a quello attuale, è buona norma, sulla scorta dell'esperienza, cercare di ricordare l'errore commesso e la soluzione adottata.

Disegnare accuratamente le mwugstrutture dati e le funzioni nella mwuwprogrammazione strutturata e le mwvaclassi in quella mwvqorientata agli oggetti è il sistema migliore per ridurre gli errori nel codice e nel facilitare l'individuazione dell'errore nel caso il programma non funzioni correttamente.

L'utilizzo di convenzioni chiare per i nomi delle mwwavariabili, mwwqfunzioni, classi, mwwgmetodi e costanti, così come quello di nomi parlanti, ovvero che rendano chiaro l'utilizzo di una componente e, soprattutto, evitare di riutilizzare la stessa componente per scopi diversi, rende più chiaro e leggibile il codice anche a fronte di una ricerca di errori.

I commenti sono fondamentali, soprattutto se il codice viene scritto a più mani. In particolare, il commento deve dare un valore aggiunto all'istruzione. Ad esempio, se l'istruzione è

non ha senso scrivere un commento come

perché si evince già dal nome delle variabili. Un commento come

è sicuramente molto più utile.

• mwzgBug

• mwaaDebugger

• mwagTest strutturale

• mwbaSistema di sviluppo

• mwbgTroubleshooting

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file sul debugging

• citerefvocabolario-treccanidebugging, su Vocabolario Treccani, Istituto dell'Enciclopedia Italiana.

• citerefbritannica-com(EN) debugging, su Enciclopedia Britannica, Encyclopædia Britannica, Inc.

• mwdq(EN) Guida a un debug rapido, su heather.cs.ucdavis.edu.